Skip to content

Stop tracking dist/ and instead automatically commit and push it to a release branch #101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Stop tracking dist/ and instead automatically commit and push it to a release branch #101

wants to merge 5 commits into from

Conversation

@dscho
Copy link
Member

@dscho dscho commented Oct 15, 2025

There is too much manual process in this repository for my liking:

  • Tags must be made manually
  • The releases must be explicitly released to the Marketplace
  • Contributors changing the logic mustn't forget to commit dist/

Let's switch this up, by no longer tracking dist/. It's now the responsibility of a new GitHub workflow to build that folder, commit and push it to the v0 release branch whenever the main branch changes.

For good measure, incremental tags are generated and pushed, too.

Obviously, this means that the new tags will not be "released" by hand, nor will they be published to the Marketplace. But that's okay, I think.

This closes #100.

@dscho dscho self-assigned this Oct 15, 2025
@dscho dscho marked this pull request as ready for review October 16, 2025 14:39
@dscho dscho mentioned this pull request Oct 16, 2025
Open
dscho added 5 commits October 16, 2025 20:23
@dscho
Add a GitHub workflow to "publish" the Action to the v0 branch
91fc67c 
With this commit, the strategy of tagging versions manually is replaced
by a workflow that automatically tags the tip of the `main` branch as
soon as it is pushed.

That relieves us from doing these releases manually, but enforces an
"always releasable" state (because `main` is released, always).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Stop tracking dist/
d01fa33 
The idea is, from now on, that the `dist/` directory will be generated
and published on the `v0` branch, not on the `main` branch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Retire the npm-run-package workflow
3281df3 
This is no longer necessary because the `dist/` directory is no longer
tracked in the `main` branch, but instead automatically generated and
pushed to the `v0` branch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Drop the dist/ verification from the main CI build
0d3deed 
... and rename it to `ci`.

The verification is no longer needed because the idea is to build and
commit this directory _only_ in the workflow that publishes `main` to
the `v0` release branch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
pre-push: no longer require dist/ to be up to date
bfc5e58 
... because it is no longer tracked.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho force-pushed the push-to-release-branch branch from 5a3e91a to bfc5e58 Compare October 16, 2025 18:26
@dscho dscho requested review from mjcheetham and rimrul October 21, 2025 13:12
@dscho
Copy link
Member Author

dscho commented Oct 21, 2025

@rimrul @mjcheetham I would like to switch to that "continuous release" model, not only for the rss-to-issues Action but also for the setup-git-for-windows-sdk and the get-azure-pipelines-artifact Actions. Opinions?

@mjcheetham
Copy link
Member

mjcheetham commented Oct 21, 2025 •
edited
Loading

@rimrul @mjcheetham I would like to switch to that "continuous release" model, not only for the rss-to-issues Action but also for the setup-git-for-windows-sdk and the get-azure-pipelines-artifact Actions. Opinions?

A few of my thoughts off the cuff:

  • how reproducible is the output of the 'compilation' (or rather transpilation for TypeScript)?
  • if we have a stable archive of the dist/ output, does it even matter?
  • is there anything only noticeable in the dist/ output that isn't in the source material? e.g. have we ever caught something by reviewing the dist/ that wasn't obvious in the src?

Other than that, I am typically pro "don't check in generated code".

@dscho
Copy link
Member Author

dscho commented Oct 22, 2025

  • how reproducible is the output of the 'compilation' (or rather transpilation for TypeScript)?

Very, once you run npm ci. Currently, we have a GitHub workflow that verifies that the contents of dist/ are identical to the result of npm ci && npm run prepare.

  • if we have a stable archive of the dist/ output, does it even matter?

Well, the Action does require the dist/ output to committed somewhere so that it can be run. Thus is the architecture of GitHub Actions.

  • is there anything only noticeable in the dist/ output that isn't in the source material? e.g. have we ever caught something by reviewing the dist/ that wasn't obvious in the src?

We haven't, but that's because we had this workflow. Otherwise it would have been relatively easy to "slip in" stuff.

On the other hand, it is utterly hard to review the dist/ contents, it's all in one, long line, variable names are shortened to save space (which doubles as obfuscation if that is your intention). But dependency updates are too large to be reviewable, anyway, there is a good deal of trust there, has to be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@mjcheetham mjcheetham Awaiting requested review from mjcheetham

@rimrul rimrul Awaiting requested review from rimrul

Assignees

@dscho dscho

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Auto-release to v0?

2 participants

@dscho @mjcheetham