Skip to content
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.

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

infra: Publish nightly releases of the Router from dev source #2409

Merged
merged 17 commits into from
Jan 20, 2023

Conversation

abernix
Copy link
Member

@abernix abernix commented Jan 16, 2023

Today, when we land features and bug-fixes on dev, they require us cutting a full release before they can be tested by interested/affected parties.

Thanks to work done in #2202 and #2323, we now have just enough automation in our release pipeline to take care of some of the necessary work for building these releases.

With some follow-up work, we can have these triggered through:

This work touches on ideas from #229 and #242, though neither of those issues are directly "build nightly releases", though I did suggest it in my comments on one of them.

Overall, this creates Router versions of the format v0.0.0-nightly+YYYYMMDD.COMMIT_HASH, which look roughly like router-v0.0.0-nightly+20220102.abcd1234-x86_64-unknown-linux-gnu.tar.gz as binaries which we can attach to non-latest releases on GitHub Releases.

Overall Plan / Follow-ups

I haven't executed this full plan yet, but the near-term follow-ups to this are:

These are still up for discussions.

Checklist

Complete the checklist (and note appropriate exceptions) before a final PR is raised.

  • Changes are compatible[^1]
  • Documentation[^2] completed
    The documentation is definitely not finished, but that's covered in Release automation improvements #2261
  • Performance impact assessed and acceptable
  • Tests added and passing[^3]
    • Unit Tests
    • Integration Tests
    • Manual Tests

Exceptions
As with most CI-based workflows, testing can be a bit challenging. Overall, this can be tested locally by emulating the steps in the CircleCI file:

  1. Being in a clean Git tree state with the PR checked out.
  2. Running cargo xtask release prepare nightly
  3. mkdir -p artifacts
  4. cargo xtask package --output artifacts/

This will need to be documented as part of #2261

While I once started using GitHub Milestones to try and actually convey what
PR landed in which released version of the Router, GitHub now does that
automatically with the advent of the "GitHub Releases" feature which
automatically puts a green callout at the bottom of a merged PR noting which
version of Apollo Router it first was published in.

As of today, the Milestones are actually being used _after_ we do a release,
which is less helpful and duplicative work.  It also has a lot of overhead
that required a lot of code to maintain.

This removes it, as discussed directly with the core team.
Today, when we land features and bug-fixes on `dev`, they require us cutting
a full release before they can be tested by interested/affected parties.

Thanks to work done in #2202 and
#2323, we now have just enough
automation in our release pipeline to take care of some of the necessary
work for building these releases.

With some follow-up work, we can have these triggered through:

- [Manual triggers] through CircleCI
- [Scheduled pipeline] runs in CircleCI

[Scheduled pipeline]: https://circleci.com/docs/scheduled-pipelines/
[Manual triggers]: https://circleci.com/docs/triggers-overview/#run-a-pipeline-from-the-circleci-web-app

This work touches on ideas from
#229 and
#242, though neither of those
issues are _directly_ "build nightly releases", though I did suggest it in
my comments on one of them.
@abernix abernix marked this pull request as ready for review January 16, 2023 14:55
parameters:
platform:
[macos_build, windows_build, amd_linux_build, arm_linux_build]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this doesn't currently actually publish anything to GitHub Releases like normal releases. Assuming these jobs don't start failing immediately, my next steps are to introduce a step that saves these to CircleCI artifacts:

      - store_artifacts:
          path: ./artifacts

Roughly documented here.

Comment on lines +634 to +635
when:
not: << pipeline.parameters.nightly >>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mildly frustratingly, this is a requirement of the way that CircleCI invokes workflows, so this will have to be present on each new workflow we may potentially add here in the future.

@abernix abernix self-assigned this Jan 16, 2023
Base automatically changed from abernix/remove-milestones to dev January 16, 2023 16:12
Comment on lines -427 to -429
- run:
name: Initialize submodules
command: git submodule update --recursive --init
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually not related to this PR, but should no longer be necessary after #1856

@github-actions

This comment was marked as resolved.

@abernix
Copy link
Member Author

abernix commented Jan 16, 2023

@abernix, please add a /NEXT_CHANGELOG.md entry for this PR to the appropriate section!

I'm going to forego the changelog until I actually test that this works.

Comment on lines +229 to +237
replace_in_file!(
"./apollo-router/Cargo.toml",
r#"^(?P<existingVersion>version\s*=\s*)"[^"]+""#,
format!(
"${{existingVersion}}\"0.0.0-nightly.{}+{}\"",
Utc::now().format("%Y%m%d"),
head_commit
)
);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This deviates from the pattern used in the other arms of the match in the way which it assigns the version. It does that because cargo set-version from cargo edit doesn't ever let you set the version lower than the current version.

I considered an approach where we instead stuck the nightly on the existing version number, but it became fragile depending on the preid (e.g., alpha, beta) and it seemed most reasonable (even in terms of defining breaking changes in the spirit of semantic versioning) that 0.0.0 was a more sensical number to use on nightlies which seemed compatible with tooling (and just thought provoking enough to humans for them to consider its meaning).

These artifacts will only survive for 30 days, but they're immediately
useful for testing the Nightly builds prior to actually publishing them.
@abernix
Copy link
Member Author

abernix commented Jan 17, 2023

The test failures are spurious and unrelated (see #2414, which I opened)

Overall, I just tested this on this PR and this appears to work at surface level! See the Artifacts tab of this PR's build.

@abernix abernix force-pushed the abernix/add-nightly-builds branch from 9f738c3 to dfc553f Compare January 19, 2023 20:19
This should probably be an xtask, but our dependency stuff is a bit haywire
in here already. (E.g., installing everything in CircleCI YAML instead of
with scripts in `xtask`).

This took a little bit of extra work because our CircleCI didn't support
installing the extra tools on Windows.
…sary

For example, not needed for nightly releases!
It uses its own escape hatch to force use of the CLI, much in the same way
that Cargo does.

This is critical for Windows.

Ref: EmbarkStudios/cargo-deny#420
@abernix abernix force-pushed the abernix/add-nightly-builds branch from dfc553f to e92a9a7 Compare January 19, 2023 21:49
@abernix abernix enabled auto-merge (squash) January 20, 2023 09:54
@abernix abernix merged commit 05ef1d8 into dev Jan 20, 2023
@abernix abernix deleted the abernix/add-nightly-builds branch January 20, 2023 10:07
abernix added a commit that referenced this pull request Mar 20, 2023
This is a small addition to #242 which, when coupled with the already-landed #2409, polishes it off nicely by letting us be notified in advance if a nightly build —which is nearly the entire release process — has succeeded or, more importantly, failed.

Without this, that functionality is less obvious and too easily missed.

Resolves #2409
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants