When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS

PeterJones

Several files should always be up-to-date with the latest release of Notepad++. One would think there might be a way to do that automatically in GitHub.

The way that immediately comes to mind would be to have a time-based GH Action in the template repo that once a month downloads the most-recent copy of Notepad_plus_msgs.h and Scintilla.h and (if there’s a change) then the action can commit it back into the plugintemplate repo. I could probably develop that GH Action, if someone else had made an Issue requesting that it get auto-updated (hint, hint, @Coises).

There’s probably some more git-centric (rather than GitHub Action) way of doing that, too, but I’m not enough of a git expert for that.

It seems like these repositories should be a GitHub template repositories.

That’s something to suggest in a separate Issue, making sure to put a link to those instructions in the request, so that Don knows how easy it is to turn it into a template. (The README could also be updated to include a summary of the instructions here for how to use a template repo to create a new repo based on that template.

I don’t know GitHub well enough to know how to automate point 1 above (or if it is possible), or if there are reasons not to do 2 or 3.

The one thing I see is that if both 1 and 3 are implemented, then the GHAction from 1 would be included when someone used the template-repo to create a new repo. It would be, in a way, “nice”, because it would make sure your plugin kept up-to-date; but it would also make changes to your plugin without your control, so it could be considered “bad”.

Coises

@PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

The one thing I see is that if both 1 and 3 are implemented, then the GHAction from 1 would be included when someone used the template-repo to create a new repo. It would be, in a way, “nice”, because it would make sure your plugin kept up-to-date; but it would also make changes to your plugin without your control, so it could be considered “bad”.

I think (but again, my understanding of both git and GitHub are very elementary) that when a template repository is used as the source of a new repository, there is no persistent connection between the two. The template just initializes the new repository with structure and files.

No one would (or should, anyway) fork the plugintemplate or plugindemo repositories. Having it be a template would just — again, if I understand it correctly — make it possible to start by making a new repository for your plugin on GitHub and then sync your local MSVC/git to that, if you preferred that to downloading the project, opening it in MSVC and then pushing it to git later.

PeterJones

I think (but again, my understanding of both git and GitHub are very elementary) that when a template repository is used as the source of a new repository, there is no persistent connection between the two. The template just initializes the new repository with structure and files.

I had never heard of the “template repo” feature until you linked it. But from my reading, when you create a repo based on that, it copies the entire structure of that repo – not as a link, but the whole structure; the GitHub Action Workflow definitions would seem to me to be part of that structure, so I would assume they would be copied; and thus, the action would still be there and active. (Again, if I understand correctly)

No one would (or should, anyway) fork the plugintemplate or plugindemo repositories.

If I understood the second page (the one I linked), it’s not a fork. But the creation process copies everything, including workflows

Coises

@PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

I could probably develop that GH Action, if someone else had made an Issue requesting that it get auto-updated

Issue #13: “Feature” request: Update files from Notepad++ automatically created.

Coises

@PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

the creation process copies everything, including workflows

Ugh. I missed that. You’re probably right, and that would be bad.

I know nothing yet about creating actions. Would it be possible to create the action so that it only runs if it is running in “nppplugins/plugintemplate” and would otherwise do nothing (unless the creator of the new repository changed it)?

PeterJones

Would it be possible to create the action so that it only runs if it is running in “nppplugins/plugintemplate” and would otherwise do nothing (unless the creator of the new repository changed it)?

Actually, I think you can; I think I have an example in one of the other actions I deal with… I’ll look into that and confirm as I work on #13.

rdipardo

@PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

Would it be possible to create the action so that it only runs if it is running in “nppplugins/plugintemplate” and would otherwise do nothing (unless the creator of the new repository changed it)?

Actually, I think you can.

An outline of such a workflow would be:

Run the build on the schedule trigger event, as already suggested in the issue thread, e.g.:

on:
  schedule:
    - cron: "0 0 1 * *" #< first day of every month at 00:00 UTC

Use the checkout Action to fetch the Notepad++ trunk
Use a diffing tool or action to compare the file paths of interest. If something changed, copy the upstream files into the template’s file paths and feed the project to MSBuild
If the build passes, push the changed files and create a release

ThosRTanner

@rdipardo Wouldn’t a better place to put the action be in the notepad++ repo so when a new version was released it’d do the updates to the template repo automatically?

@PeterJones @Coises thanks for all the replies and though processes on this.

ThosRTanner

@PeterJones you’d be surprised how much I don’t know despite having hung around for a long time

rdipardo

@ThosRTanner said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

@rdipardo Wouldn’t a better place to put the action be in the notepad++ repo so when a new version was released it’d do the updates to the template repo automatically?

You make a good point.

The workflow steps would essentially be the same, but in the opposite direction (clone the template repo, update the file tree, validate the build and push if successful). The main difference would be the trigger; ideally you would want to watch for tagged Notepad++ releases, e.g.,

on:
  push:
    tags:
      - 'v*'

This way new template versions can be explicitly tied to a Notepad++ release, e.g.,

# 'refs/tags/vX.Y.Z' -> 'vX.Y.Z'
echo "NPP_RELEASE=${env:GITHUB_REF}.Split('/')[2]" >> $env:GITHUB_ENV
# ...
git tag -a "${{ env.NPP_RELEASE }}" '@' -m "plugintemplate-for-Npp-${{ env.NPP_RELEASE}}"
git push --tags --repo=https://github.com/npp-plugins/plugintemplate

But it would be a problem if incompatible changes were made to the template. A failed build would cause a red X to appear beside the tagged Notepad++ commit, giving the false impression the release was a botch.

I think the separation of concerns principle is best observed if the template project looks after its own updates. A little extra churn won’t be a great inconvenience. The majority of plugin authors are still copy-pasting the template files into their source tree, as shown by how many have “C” as their detected primary language, since the template files contain no unique C++ syntax or standard headers, which GitHub relies on to classify header files, unless you manually override the heuristics.